摘要：我对AIagent的期待，不是“更像人”，而是“更少磨损地放大我自己”。真正的瓶颈仍然是人：我稳定能同时调度的事情只有2–3件，所以一个好agent必须满足三个条件：少打扰我、多替我工作、结果足够可靠。,一月对于 Coding Agent 的思考 一月对于生肖兔,羊,鸡哪天适合封顶
这篇文章是我和 Chatgpt 一起写的。我的观察是：Chatgpt 逻辑能力很强， 然而中文表达实在是太怪了，不知道跟谁学的中文。凌晨的告警把我从床上拎起来的时候，我就知道今晚的结局了：告警会有用， 然而日志会很垃圾。屏幕上 CPU 的峰值像一根针，扎破了 体系“看起来还行”的气泡；而我盯着那堆复盘不了的 log，心里又记了一笔——可用性不是靠祈祷堆出来的。也是从那一刻起，更让我确定了一件事：我现在做的其实不是“用 AI 写更多代码”，而是用 AI 把自己 scale 起来。先把我从执行者的位置挪出来，变成指挥、验收、 并且负责迭代这个 体系的人， 接着再去尝试用这个 体系来 scale 别人。这篇随笔就从这个主题说起。我把多代理开起来，花费 token，感受到仿佛造物主的乐趣。 接着紧 接着就撞上项目的“隐含 智慧墙”，又被迫把评估、汇报、记忆这些“看起来不性感的 物品”一件件捡起来。中间穿插感冒、做饭、桌游、换编辑器——它们不是偏题，它们是我这套 体系真正的约束条件：我只有一个大脑，一天只有 24 小时，而且真的会累。初尝 scale 的甜蜜点
这天，我把 opencode 的 multi-agent 模式真正用起来了：五个 agent 同时改五个 难题。那两小时的体验很像我第一次跑通 6.824 的第一个作业：本地跑起来一个分布式的 MapReduce 体系——日志刷得飞快，任务被同时推进，我的生产力从“手工耕作”变成了“机械化收割”。在这个 经过里，我的 Codex Plus plan 的每周 token 限制也第一次如此迅速地被用完了。并行这件事很容易让人上瘾， 由于它让人感觉太好了：不需要一直盯着，我甚至能短暂地相信自己已经摆脱了瓶颈。但并行的代价也很直白：成本线性，且错误会被放大。如果一开始 路线错了，多代理不是“多条路试试”，而是“五辆车一起开进沟里”。 因此我对“自治”的定义，很快就从一句口号变成了三个具体的目标——我把它写得像 SLI：- 尽量少来打扰我（降低中断的成本）
- 它尽量多 职业（ 进步有效产出）
- 尽可能提升可靠性（不要偏航、不要闪退、不要把我拖进返工的泥潭）
这三个目标后来反复出现，成了 LegionMind 所有设计决策的北极星。瓶颈是我自己
把执行 职业尽量丢给 agent 之后，人类的理性和欲望就成为了推进 职业的瓶颈。我的 职业流大概是这样的：开发、日常安排、 思索与输出——我最多同时稳态运行两三个上下文。超出这个范围，我的调度就会失灵，疲惫会像内存泄漏一样慢慢堆起来。多代理 体系并没有消除这个 难题，它只是把“执行负担”挪走了，但上下文管理、验收、决策，还是得我来，而且 由于 AI 做执行真的很快，因此其他方面的负担变得更重了。后来我开始更 诚恳地看待“ 职业日志”这件事，才有了这个 2026 职业日志。我在里面也提过，写它不是为了未来回忆细节，而是为了把上下文从脑子里卸载出来。记录本身就是一次 思索链条的整理，像把内存里的脏页做整理后刷回磁盘。我甚至发现，日志如果变成“必须坐下来写三 特别钟”的仪式，就会让人恐惧；一恐惧，就会停更；停更几天，就越积越多， 最后更难写。 体系设计再漂亮，落到人的 习性上，还是会被现实击穿。有关这点，我还在探索，下面还是言归正传，谈谈 AI 吧。“隐含 智慧墙”，当我们给 AI 下达指令时，我们在期待 何？
当我真正把 agent 推进到复杂项目里——尤其是那种 monorepo、跨多个 package 的项目——一个典型事故出现得非常快：我让 agent 参考某个类似的实现（比如 vendor-okx）去接入一个新模块。 结局它不仅学到了正确的写法，也学走了过时的 操作：对于我自己的案例来说，这个过时的 操作是把账户流写进了一个已经不用的入口。对我来说，这是“项目早就演进过的常识”；对一个新 agent 来说，这些演进是不可见的。那一刻我 觉悟到：agent 的“ 进修”更像是从可见样本做拟合，而不是从组织记忆里 领会历史。它并不知道 何是“现在的标准”。于是“外置大脑”从锦上添花变成了必需品。但外置大脑也有一个残酷的代价：维护它本身会消耗注意力，而注意力正是我最缺的资源。我曾经尝试用一组 AGENT.md 做项目记忆，但很快就碰到难点： 如何区分 何是噪音、 何是值得固化的经验？这不是文档写作的 难题，这是评估 难题——你必须知道 何会导致 agent 翻车、 何能显著 进步它的通过率，才值得写进“记忆”。当我们给 AI 下达指令的时候，我们究竟在期待 何？把这层结构整理成一个“指令/ 智慧分层”的框图，就会得到如下 结局：┌────────────────────────────┐
│ ① 本次任务指令（你能说清的） │
├────────────────────────────┤
│ ② 项目技术决策/局部最佳 操作 │ ← 最容易“隐含”，也最容易翻车
├────────────────────────────┤
│ ③ 领域背景（ 难题是 何） │
├────────────────────────────┤
│ ④ 工程常识/风格偏好/经验积淀 │
├────────────────────────────┤
│ ⑤ 全球背景 智慧 │
└────────────────────────────┘
在一次对话里，真正能清晰传达给 AI 的，只有最上面那层。结论是：上下文越小、指令越清晰、历史包袱越少，AI 越容易高质量完成。隐含背景越多，越容易出现“莫名其妙的活”。这也是 LegionMind 诞生的 缘故。不要求下达指令的人“能写出一个完美的 prompt”，而是要把第二层的隐含 智慧，变成可以被加载、可以被复用的 物品。意图对齐 + 分层验证
目前版本的 LegionMind 会强制要求 Agent 根据用户指令，收集项目相关信息，写成一份详尽的 RFC 式的文档，力求在一开始最大程度地对齐用户需求。 缘故很简单：当 multi-agent 体系开始翻车，人类的第一反应往往是：写更长的 RFC、做更严格的 review，把风险压到最前面。人和 AI 的协作会被推回一种近似瀑布流的形态：线性推进、灵活性差，不过要命的是：给我带来的心智负担会比较大。人类的组织 怎样做到让上层决策者不用被信息淹没呢？人类的决策者 怎样做到让属下放手去做呢？对次 CZ 有一些 思索本质上就是：意图对齐：让 agent 不偏航分层验证：让错误尽早暴露，且可以轻易回滚，而不是 最后才发现 路线错了这不是空话。我给它配了一个“生产流水线”式的流程图，用来约束自己和 agent 的交互方式： ┌──────────┐
│ Intent │ 目标/约束/不做 何
└────┬─────┘
│
┌────▼─────┐
│ Plan │ 拆解、里程碑、假设
└────┬─────┘
│
┌────▼─────┐
│ Execute │ 写代码/改配置/生成文档
└────┬─────┘
│
┌─────────▼─────────┐
│ Verify │ 分层验证（越便宜越先跑）
│ - build/lint/test │
│ - e2e/bench │
│ - model eval │
│ - hu n review │
└─────────┬─────────┘
│
┌────▼─────┐
│ Report │ 结论 + 证据 + 风险
└────┬─────┘
│
┌────▼─────┐
│ Memory │ 固化“值得记”的差异点
└────┬─────┘
└──(反馈回 Intent/Plan：形成闭环)这个流程的关键不是“更复杂”，而是把验证前移、把反馈变成闭环。它能对抗两种最常见的损耗：- 路线错了还持续并行推进（token 大出血）
- 路线对了但细节不可靠，导致反复返工（心力磨损）
评估的两套语言：pass@k 和 pass^k
有一篇有关 怎样评估 AI Agent 的表现的文章，对我很有启发。使用 AI 来完成任务的时候，一般来说分为做两种完全不同 职业类型：- 能力探索型：不在乎一次就对，只想知道“它有没有可能做到”。这时关注的是 pass@k——k 次尝试里至少成功一次。
- 生产回归型：不接受“偶尔可以”，需要“每次都可靠”。这时关注的是 pass^k——k 次尝试必须全部成功。
同一个 体系，在不同阶段应该用不同指标说话。能力探索阶段可以少说多听，让 AI Agent 充分发挥它 丰盛博学的 全球背景 智慧；回归阶段我们必须盯住一致性。 ┌────────────────┐
│ Hu n Eval │ 人看设计/风险/边界条件（最贵）
├────────────────┤
│ Model Eval │ rubric/对齐/一致性检查（中等）
├────────────────┤
│ Static / Tool │ build/lint/unit/e2e（最便宜）
└────────────────┘
制度很简单：能用工具判断的，尽量减少认知消耗。“汇报接口”是被低估的工程 难题
前面章节谈的都是“ 如何让 agent 做事”。除此之外的另一个重点是“ 如何让我低成本验收”。这部分我还在 思索之中，不过有一些间简单的想法，可以顺便在这里谈谈。核心的想法在于：AI 的汇报不能停留在平铺的 Markdown 和代码 diff。在人类组织里，下属汇报往往需要 PPT，甚至需要一个中层做“昂贵的传声筒”，把复杂信息压缩成可决策的结论、证据和风险。那么 AI 的 report 应该是 何？一个非常具体的想法：每一条结论都应该 link 一个 artifact。比如：- “这个功能已完成” → 链接到 e2e 测试报告、关键 diff、复现实验脚本
- “这个选择更好” → 链接到 bench rk 对比、日志证据、配置变更
- “这里有风险” → 链接到已知不确定性列表、回滚方案
甚至可以有一个专门的 Citation Agent：它不写代码，它只做一件事——把结论和证据绑在一起。汇报接口变好，人类才能更放心，自治才真正成立。否则 agent 写代码的能力再厉害，我也还是要把大量精力花在“读它写的 物品、猜它到底做了 何”上面——这和我想要的“少磨损”是冲突的。工程化迭代
到了二月，Chatgpt codex 5.3 发布了，体验上确实让人感觉非常 智慧。我也因此有了一个担忧：把 workflow 规定得太死，会不会反而浪费了 AI 的潜力？LegionMind 一直以来在尝试的是：给定一个确定的框架、给定一个领域中比较成熟的 SOP(上面的 3、4 层)，让 Agents 在给定的轨道里跑，减少偏航。但当模型更 智慧时，也许更合理的方式是——我只给目标、约束、评估机制，让它自己设计最合适的路径。这也意味着另一件事必须发生：我得用更科学的方式比较不同版本 体系的表现，而不是凭感觉说“这版更 智慧”。于是“bench rk”在我脑子里从一个念头变成了刚需：我需要一套复杂编码任务的回归测试，用同一组任务去量化：- pass@k（能力探索）
- pass^k（生产可靠）
- 成本（token/ 时刻）
- 返工率（人类介入次数、修改轮次）
- 覆盖面（跨项目、跨 package 时的稳定性）
只有这样，我才能真的“迭代 体系”，而不是“迭代心情”。有关这方面的 事务，我接下来会做两件事：考察市面上的 LLM Coding bench rk 看看有没有 何可以直接拿来用的。根据我们的实际场景，设计一套 bench rk （LLM 面试题）让不同版本的 LLM 和 Legion 来完成任务。甚至可以做一个 360 环评。8. 里程碑
有一个晚上，我使用这套 LegionMind 体系终于把一个横跨多个 project 的 http-proxy 任务终于做通了。 经过并不优雅，甚至触及了当前 体系的极限——subagent 偶尔闪退，跨 package 的上下文让多代理协作变得脆弱。但 结局 一个我很在意的里程碑：我基本可以脱离编码了。多数情况下，我只需要留下少量对设计文档的 review comment。这样的变化让我感到非常舒适：从键盘执行者变成审阅者、决策者、 体系迭代者。也就是我一开始说的：把自己 scale 起来。与此同时，我也更愿意承认一条现实 制度：不要做容易被海浪拍死的轮子。我发现某个能力平台本身在演进（比如 opencode 已经在做某些 bridge 能做的事），宁愿先 hold 住，也要把精力投到“会随着海面上升一起上升”的 体系层能力上——评估、记忆、汇报、可靠性。我和 AI Agent 的互相驯化
写到这里，我发现这一个多月里，我和 AI agent 其实在互相驯化：- 我驯化它：用 SOP、验证、汇报接口，把它从“会写代码的模型”推向“可交付的 体系”。
- 它驯化我：逼我承认人的瓶颈、承认评估的重要、承认组织与流程才是 难题的核心。
如果要把这段经历压缩成几句话，我现在大概相信：自治不是 智慧就够了，是少打扰、多产出、可验证。最昂贵的不是 token，是返工和注意力泄漏。隐含 智慧比代码更容易让 agent 翻车。外置大脑必须有，但必须可维护。验证要分层，目标要分阶段：先 pass@k，再 pass^k。AI 的汇报接口必须工程化：结论要带证据，最好能一键指向 artifact。当模型变强，流程可能要放权给 AI；但放权的前提是你有 bench rk。接下来我大概会继续做两件事：一是把 bench rk 体系搭起来，让“迭代 legion/多代理 体系”变成一件可度量的事；二是把 report/citation/artifact 这条链路补齐，让我能更轻松、更稳定地把 事务交出去。至于那句最朴素的 梦想——“尽量少磨损”——我现在觉得它不是 梦想，它应该是 体系的非功能需求。只要我还在写代码、还在被告警叫醒、还在玩桌游和做饭，这个需求就永远成立。
